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At least one drawing originally filed was informal and the print reproduced here is taken from a later filed formal copy. 
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Rule Strengths of Selected Rules for 
the Sprinkler Control System 



Air Temperature = 92° F, Soil Moisture =11% 



"If temperature is hot (46) AND soil is 
dry (25), then water duration is long" 

"If temperature is warm (2) AND soil is 
moist (75), then water duration is medium" 

"If temperature is warm (2) AND soil is 
dry (25), then water duration is long" 



"If temperature is hot (46) AND soil is 
moist (75), then water duration is medium" 
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FEATURE INTERACTION RESOLUTION USING FUZZY RULES 

FIELD OF THE INVENTION 

5 This invention relates in general to communications systems, and more 

particularly to a method of resolving conflicts between multiple agents in an open 
standards-based communications system. 

BACKGROUND OF THE INVENTION 

10 

The evolution towards the design of multimedia communications systems 
based on open standards has been ongoing since the 1980s. One example of such a 
system is the MediaPath* communications server manufactured by Mitel Corporation. 
The MediaPath* system comprises call control software which operates in 
15 conjunction with a plurality of server telecommunication boards (voice processing 
board, trunk board, line board, etc.), as described in hm>://\\-ww.miteI coTn/MediaPath 
(1997). 

In R. Buhr, D. Amyot, M. Elammari, D. Quesnel, T. Gray, S. Mankovski, 
20 "Feature-Interaction Visualisation and Resolution in an Agent Environment", edited 
by K. Kimbler andi.G. Bouma, p. 135-1 49, a multi-agent architecture is set forth 
wherein each physical device is represented by a device agent that is responsible for 
handling and controlling all requests and actions of the device. The device agent may 
contain multiple feature agents, which are responsible for implementing the various 
25 features to which the device has subscribed. The end user may also be represented by 
a user-agent, which contains all of the preferences of the user. 

Feature interaction occurs when two or more agents want to apply different 
policies whose actions or goals conflict. Detecting and resolving feature interactions 
30 has been an active area of research (see for example L. G. Bouma, H. Velthuijsen, 
editors: "Feature Interactions in Telecommunications Systems", ISO Press, 
Amsterdam, 1 994, 272 pp.; K. E. Cheng, T. Ohta, editors: "Feature Interactions in 
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Telecommunications III", ISO Press, Amsterdam, 1995, 223 pp.: P. Dim. R. Boutaba. 
L. Logrippo, editors: "Feature Interactions in Telecommunications Networks IV", ISO 
Press, Amsterdam, 1997, 373 pp.; and K. Kimbler and L.G. Bouma, "Feature 
Interactions in Telecommunications and Software Systems V", ISO Press, 
Amsterdam, 1998, 374 pp.). Several approaches to solving the problem of feature 
interaction are also set forth in A. Aho, N. Griffeth, "Feature Interactions in the Global 
Information Infrastructure," in Foundations of Software Engineering, Washington, 
October 1995. 

One common aspect to all of the prior art solutions to the problem of feature 
interaction is that the end user has no control of the outcome of the feature 
interactions. The systems according to the prior art predefine the result of feature 
interactions, without taking into consideration the parameters that are relevant to the 
end user, such as, the source of the call or the time of day. For example, the system 
disclosed in R. Buhr, et al uses an absolute priority mechanism to resolve conflict 
between multiple agents. In that system, a PROHIBIT action always take precedence 
over a FORWARDTO or a PERMIT action, with the result that the end user cannot 
affect the result of a feature interaction. 

20 SUMMARY OF THE INVENTION 

According to the present invention, an architecture of multiple agents is 
provided, based on the negotiating agents' approach to resolving feature interactions, 
as set forth in R. Buhr, et al, discussed above and N. Griffeth, H. Velthuijsen, "The 
Negotiating Agents Approach to Runtime Feature Interaction Resolution", in Feature 
Interactions in Telecommunications Systems, IOS Press, Amsterdam, May 1994. 
However, according to the present invention, an event-based model is used to detect 
feature interaction, and fuzzy constraints are applied to the policies that descnbe the 
system. A mechanism is established by which the user may add rules or prov.de the 
30 system with parameters that will affect the outcome of any conflict that may occur, 
thereby giving real control over the conflict to the end user. 
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BRIEF DESCRIPTION OF THE DRAWINGS 



A detailed description of a preferred embodiment of the present invention is 
provided herein below with reference to the following drawings, in which: 

Figure 1 is a schematic representation of a multi-agent communication system 
in accordance with the present invention; 

Figure 2 is a message diagram for illustrating event request registration, event 
posting and conflict detection in a multi-agent system according to the present 
invention; 

Figure 3 is a depiction of a an exemplary fuzzy rule-based control system for 
showing the principle of fuzzy rules; 

Figure 4 is message diagram showing a first application of fuzzy rules to 
arbitration between multiple feature agents according to the present invention; and 

Figure 5 is a message diagram showing a further application of fuzzy rules to 
conflict resolution between multiple agents system according to the present invention. 

^ '. 
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

With reference to Figure 1, a multi-agent communication system is shown 
comprising a MediaPath"* server for controlling calls between users at various 
telephone devices, and a MicMac" tuple space (see, for example, D. Gelemter , 
"Generative Communication in Linda" in A CM Transaction on Programming 
Languages and Systems, Vol. 7, No 1, pp. 80-1 12) for communicating between 
multiple agents, as discussed in http://micmac.mitel.com/. Thus, a first user is 
represented by a user agent (User 1) which issues preferences defined by that user, a 
POTS (plain old telephone set) is represented by a device agent (Agent A), a mobile 
telephone is represented by another device agent (Agent B), and a digital phone is 
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represented by a further device agent (Agent C). The physical devices are connected 
to the MediaPath server which implements the agent communication architecture via a 
publish-subscribe mechanism using the MicMac tuple space. Thus, an Event Agent 
communicates with each of the Agents A, B and G for invoking operations using 
tuples (a set of ordered pairs called ingles). Each ingle consists of 4 type (e.g. From) 
and a value (e.g. A). Thus, an exemplary tuple would be: { : From A :To B xallld id) . 
This tuple describes a call request from A to B. The tuple space enables coordination 
by allowing queries based on the matching of tuples by anti-tuples. An anti-tuple is a 
tuple that can be used as a query in the tuple space. In form, it is identical to a tuple 
except that the value of any or all fields may be replaced by a <?', which indicates a 
'don't care' condition, similar to a template. Tuple spaces are set up to match tuples 
with anti-tuples which agree in all fields except for the ones indicated by the *?' 
query, similarly to Prolog unification. Four operations on the tuple space have been 
defined; poke, peek, pick and cancel. Poke places a tuple in the tuple space. Peek 
5 queries the tuple space with an anti-tuple (matching tuples will remain in the tuple 
space). Pick also queries the tuple space with an anti-tuple (but matching tuples will 
be removed from the tuple space). Cancel removes all matching anti-tuples from the 
tuple space. A lifetime for tuples can also be defined. 

> 0 According to the preferred embodiment of the invention, a policy notation is 

adopted as set forth in D. Marriott, "Policy Service for Distributed Systems", Master's 
thesis, Imperial College of Science Technology and Medicine, London, UK, 1997, p. 
131. The general format of this notation is given below, with optional arguments 
written within brackets. 

PolicyJDmode /trigger/ subject® {actions} target(s) /when constramt(s)/ 

The Policy JD is an identifier that uniquely identifies the policy within the 
system. The mode of a policy can have one of the following values: A + is used to 
30 represent positive authorization mode, which represents the permitted actions; A- is 
used to represent negative authorization mode, which represents the forbidden actions; 
Q+ is used to represent positive obligation mode, which represent the actions that the 



agent must perform; and O- is used to represent negative obligation mode, which 
represents the actions that the agent must prevent from occurring. Triggers are used 
only with obligation (positive or negative). They specify the events the agents should 
react to. 

Subject(s) are the agent(s) that are responsible for carrying out the actions 
described in the policy. 

Target(s) are the objects that will be affected by the actions. 

Constraints are the pre-conditions that must be realized for the policy to be 
applicable. Constraints can place conditions on the subject, target or mode of the 
policy or on the state of the system. 

As shown in Figure 1, the system of the present invention is an event-based 
model to detect feature interactions. An event represents the occurrence of an action, 
for example, On-Arrival 9 Call-RequesU On-Exception y At-Time = X. These events 
represent user actions, system actions or agent requests. 

Event-based systems are composed of three major components, an Event 
Blackboard, an Event Agent and an Arbitrator. Events are posted on the event 
blackboard, which is implemented by Micmac, as shown in Figure 1. Each agent 
registers for all of the events it is interested in with the Event Agent. Two levels of 
registration exist: notification and handling. An agent may want to be notified of the 
occurrence of an action in order to change its internal state or to start a set of actions. 
One example is a cost agent, which is responsible for calculating the cost of using a 
service, which wants to be notified when a call is established to start calculating the 
resulting cost. The second level of registration is handling. In this case, the agent 
wants to have a monopoly over control of an event. One example is when a call 
request to a specific device is made. A termination-call-screening agent wants to be 
allowed to refuse the call if the caller is on its screening list, and it wants to prevent 
any other agent from trying to process the call. It must be notified that in this case, the 
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termination-call-screening agent does not oppose notification of another agent of this 
call attempt. 

A conflict occurs when two or more agents want to handle the same event. 

5 Conflicts can occur on two levels, either between several device-agents, or inside a 
single agent (between two or more feature-agents). According to the present 
invention, conflict is first resolved at the agent level, so that an agent only proposes a 
single action in response to an event. Each agent is free to choose the method used for 
solving the conflict at the agent level. In the preferred implementation, fuzzy logic is 

10 used, as discussed in greater detail below. 

Conflict between multiple agents is resolved via a special purpose agent, 
commonly referred to as an arbitrator. Arbitrators can be either passive or active. A 
passive arbitrator does not control the conflict, but rather only detects the occurrence 
of a conflict and opens a separate channel for the conflicting agents to negotiate and to 
come up with a suggestion for all of the conflicting agents to agree on. The suggested 
action is posted on the Event Blackboard as a request made by all of the agents that 
participate in the conflict resolution. There is no guarantee that the rest of the agents, 
which did not participate in the previous conflict, will agree on this suggestion. On the 
other hand, an active arbitrator takes all the proposed actions of the conflicting agents 
and, using some heuristic, chooses one of these actions. Usually, the active arbitrator 
is used when a priority mechanism can be defined. According to the present invention, 
^passive arbitrator is utilized, and the negotiation between agents involves the use of 
fuzzy logic. 

Conflict can also occur if an agent wants to perform an action on another agent 
without having the permission to perform such an action. In this case, the two agents 
enter a negotiation phase, trying to reach an agreement, which may involve one agent 
paying a certain cost to the other agent in order to allow the action. If no agreement is 
reached at the end, an Exception event is generated and posted on the Event 
Blackboard. 
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When an event occurs, all of the agents that have been registered for the event 
are informed. If all of the preconditions that are associated with that event are 
realized, the agent will suggest an action. If not, the agent will reply with 'Wo Action". 
The arbitrator waits until it receives a reply from all of the agents registered to handle 
5 the event. If more than one agent replies to the event, the arbitrator detects the 
conflict and intervenes so that only one action is chosen. If no agent is registered to 
handle an event, or if all of the agents reply by a "No Action", the event is 
automatically removed and the arbitrator agent is notified ( to accommodate the 
possibility of the occurrence of a state that was not taken into consideration during the 
10 design of the system). 

The Event Agent is responsible for handling event registration, event posting 
and conflict detection, as shown in Figure 2. 

15 When the event agent receives an event request from Agent A, the event 

agent creates a new instance of the RequestHandler class, and generates a unique key 
called requestHandlerJdentifier. The event agent adds the generated object to a 
Hashtable, called RequestHandler Pool, in which the agent keeps a reference to all of 
the generated requestHandlers, with the requestHandlerJdentifier as a key. 

20 

The RequestHandler object is responsible for handling individual event 
requests. Thus, if Agent A wants to be notified when a Call-Request is sent to it, the 
RequestHandler object will post the following peek anti-tuple on MicMac. 

• EventName: CallRequest {the name of the event}. 

25 • Eventldentifier: any {a unique identifier for the event} 

• Parameters: any {a tuple containing a list of additional parameters}. 

• Type: (zero or 1) {depending on the registration level {notification or handling)}. 

• From: any {the sender of the call request} 

• To: A {the receiver of the call request} 

30 

The Parameters ingle, which is an inner : tuple (i.e. an ingle whose value is a 
complete tuple), contains a list of optional parameters that can be associated with the 
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event. A parameter that is not in the list of parameters is interpreted as having a value 
of zero. In fact, the event request may involve some conditions involving logical 
operations and parameters relevant to the current state of the requesting agent or the 
system state. An agent, for example, may be interested only in a call request if the call 
importance is greater than 50%. In this case, the RequestHandler object registers for 
the events as described above, with the parameters value "any". 

If a tuple is retrieved, as discussed below with reference to event posting, the 
RequestHandler object sends the tuple to the agent that owns the RequestHandler 
object (Agent A in Figure 2). The latter tests all conditions of the rule and returns a 
boolean value (i.e. true/false), referred to as a result, that indicates whether all of the 
pre-conditions were satisfied or not. The RequestHandler object then sends a 
response to the event agent, as discussed below. 

5 When the event agent receives an event (e.g. from Agent Bin Figure 2), the 

event agent creates a new instance of the EventHandler class, and generates a umque 
key referred to herein as Eventldentifier. The event agent adds the generated object 
to a Hashtable, called EventPool, in which the agent keeps a reference to all of the 
generated EventHandlers, with the Eventldentifier as a key. 

Thus, if Agent A wants to post a call request to Agent B, the EventHandler 
object posts the following tuple on MicMac. 

• EventName: CallRequest {the name of the event). 

• Eventldentifier: Eventldentifier 

25 . Parameters: any {or the tuple of parameters if any}. 

• Type: any. 

• From: A {the sender of the call request} 

• To: B {the receiver of the call request} 

30 The EventHandler object then waits for a given duration to receive all of the 

forwarded responses of the RequestHandler objects, as discussed above. The 
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parameters of these responses are locally stored in a Vector which, as discussed 
above, is called responses. 

After this duration, the EventHandler object removes the tuple from MicMac 
5 (using a pick anti-tuple). Then, the EventHandler object issues a re-post request for 
each of the RequestHandler objects stored in responses, so that they re-post their 
anti-tuples again to wait for new events. 

If no response is received, the event is registered in a log file to indicate the 
10 occurrence of a non-handled event with all of the corresponding parameters, as 
discussed above. 

An event notification will be sent to all the requesting agents whose request 
type is notification. If only one RequestHandler object wants to handle the event, an 
15 event notification is sent to the requesting agent (Agent B). If more than one 

RequestHandler object wants to handle the event, the EventHandler object informs 
the event agent which, in response, invokes the arbitrator object, as discussed in 
greater detail below. 

20 As discussed briefly above, fuzzy constraints are applied to the policies that 

describe the systenyaccording to the present invention. Before discussing the 
application of fuzzy rules to the system of the present invention, a brief introduction 
to fuzzy logic is presented herein below. 

25 Much of human reasoning involves the use of linguistic variables, that is, 

variables whose values are words rather than numbers (e.g. the "temperature" is 
"hot"). Thus, human perception of an ambient temperature of 80° F may be rather 
hot, but it is also considered to be warm to some degree. Thus, the fact "temperature is 
hot" has a degree of truth (or degree of membership) that is partially true and partially 

30 false at the same time. Classic logic is too rigid to be able to express this concept, as it 
assigns only a value of true or false to the predicate "hot". Fuzzy logic is the branch of 
mathematics that is concerned with modeling information based on membership 
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arades (see E. Cox, -The Fuzzy Logic Systems Handbook-, AP Professional. 
Cambridge, 1 994. p 624, and Motorola Corporation, 'Fuzzy Logic Education 
program'. The Centre for Emerging Computer Technologies. Motorola Inc., 1992). 

- The first step in fuzzy logic processing is to transform crisp inputs to fuzzy 
inputs. The rules are than evaluated and the fuzzy output is transferred back ,o a crisp 
output. In the system of the present invention, real-world modeling is accomphshed 
lh r„„gh fire use of fuzzy variables and sets of rules. In order to decide which rule to 
apply when modeling a system, the value of U>c fuzzy input variables must first be 
determined. Then, dr. streng* of each rule is calculated by giving it the smallest 
snength value of fire fuzzy inputs of its antecedents. The suengfi, of Ore ru.e expresses 
how suitable the action suggested by the rule is to handle a given situation. The acnon 
tha. is suggested by the rule having fire highest rule strength is considered tire best 
alternative and thus is chosen by the system. 

Figure 3 shows an example taken from me Motorola reference cited above. In 
to example, tire duration of a sprinkler control system is determined using fuzzy 
rules The first step involves .nmsforming the input from crisp to fuzzy mpurs 
(fuzzification). A temperature of 92' F is interpreted, using the Warm and Ho, 
UentoersMp Junction of Figure 3, as being 20% warm and 46% hot A soU-morsture 
of 11% is considered as 25% dry and 75% moist. These values of these input vanab.es 
are used in the fuzzy rules, and the streng* of each rule is deduced. The rules sugges, 
a ,ong watering duration, with a .nub-value of 25% (the highest suggested truth-value 
for a given fuzzy output value). It also suggests a normal duration with a truth-value 
of 46%. To determine tire actual watering duration, tire opposite process of 
fuzzification is applied to obtain the crisp value of the watering duration. 

I. the system according to the present invention, the de-fuzzification step U 
no. used. Fuzzy logic is used only to determine which action is most suitable to 
, handle a given situation, no. «o obtain a specific value for an output vanable. 
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Fuzzy inputs are used in the present invention to allow the user to express 
concepts such as importance of a call, how busy a user is, or what time is more 
suitable for the user, as discussed in greater detail below. 

In many cases, there is more than one acceptable outcome to a conflict 
between multiple agents. The end user may prefer one action to another, but one or 
more other actions may be acceptable to the user. Stated in terms of fuzzy logic, no 
rule is 100% acceptable (or true). Rules are only partially true. Thus, fuzzy logic 
constraints are used in the present invention to express these policies. The values of 
these constraints can be a parameter taken from the user-agent, which expresses the 
user preference. These constrains can also involve parameters from the event object, 
which are set by the requesting agent or the system itself. In the following portions of 
this disclosure, more detail is provided on how these parameters are set and used in 
accordance with the present invention. 

As set forth in Figure 1, each user is represented in the system by a user agent 
This agent contains the preferences of the user, expressed using fuzzy variables. The 
user agent also contains information about the schedule of the user as well as 
constraints that the system imposes on this user. The user expresses his or her 
preferences by choosing values to fuzzy attributes like ForwardToSecretary, which 
expresses how much the user likes to be forwarded to the secretary of a person. The 
user can also add personalized rules like: 

Pl_al 0+ [on MeetingManager] agent {set(0.95)} agent.busyState 

The foregoing rule indicates that when a manager meeting begins, the system 
should consider the user to be very busy. The busyState parameter is taken into 
consideration when searching for a suitable action, to prevent unnecessary interruption 
of the user. The reasoning mechanism is discussed in greater detail below with 
reference to Figures 4 and 5 through the use of examples. 

When a device is being used by a specific user, the user agent is contacted, and 
all of the rules that reflect the user preferences, as well as the fuzzy inputs, are added 
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to the device-agent rules and parameters. For simplicity, the examples set forth below 
with reference to Figures 4 and 5 are shown after that the device agent has loaded the 
user's preferences. 

- As indicated above, events are modeled as objects with attributes. An event 
has a type, like Call-Request, On-Exception, which represents the class name of the 
event. An event object may have a number of variables such as an indication of the 
object(s) that generated the event, the time when the event was generated and the 
receiver of the event. An event can also have a variable number of associated fuzzy 
variables. An event such as Call-Request has a fuzzy variable called /m^r/once, 
which indicates the importance that the caller gives to a particular call. The receiving 
agent has also the right to modify this parameter to reflect the importance that the 
receiver of the call is giving to the caller. The event object may also contain 

parameters that express how the requesting agent would like his/her request to be 
treated. For example, the Call-Request event has an associated fuzzy parameter called 
no-Forward that indicate that the caller does not like his/her call to be forwarded to a 
third party. It should be noted that the system need not necessarily abide by a user's 
preferences. 

The use of fuzzy logic in conflict resolution is hereinafter described in greater 
detail, by reference>to specific example scenarios; 

In the example of Figure 4, fuzzy logic is used to arbitrate between two 
modules at the agent level. More particularly, an example is set forth of a conflict 
between Call Waiting (CW) and Answer Call (AC). CW generates a call-waiting tone 
to alert the called party, whereas AC connects the calling party to an answering 
service. If A is already on the line when the second call comes in, should A receive a 
call-waiting tone or should the second call be directed to the answering service? The 
previous example is classified as a Single-User-Single-Component (SUSC), as 
disclosed in J. Cameron, N. Griffeth, Y. Lin, M. Niison, W. Schnure, H. Velthuijsen, 
"A Feature Interaction Benchmark for IN and Beyond". In L. G. Bouma, H. 
Velthuijsen, editors. "Feature Interactions in Telecommunications Systems", ISO 
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Press, Amsterdam, 1994, p. 1-23, where the interactions occur because incompatible 
features are simultaneously in use by a single user in a single network component. 

In this example, it is assumed that the user has expressed that he or she does 
5 not want to be interrupted during a long-distance telephone call. Thus, AC should 
take precedence over CW when the other call is a long distance call. Otherwise, CW 
should take precedence over AC 

The preferences of the user are modeled using the following rules. 
10 • Pl_al 0+ [on CR:CallRequest] agent (set(0,6) } CRAmportance 

• Pl_a2 0+ [on CR:CallRequest] agent {set (0.9) } CRAmportance [when 
CRAsLongDistance] 

• Pl_a3 0+ [on CEiCallEstablishement] agent {set (0.9* CE. importance) } 
agent xurrentCallAmportance 

15 Rule Plj2l stipulates that when a call request is received, then the call importance 
(C importance) is set to 0.6, while rule Pl_a2 stipulates that the importance of the call 
be set to 0.9 if the call is a long-distance call. Rule Plja3 stipulates that once the call 
has begun, the call importance is to be reduced to 90% its original value. 

20 The Answer-Call agent contains the following rule. 

• Pljicl 0+ [on CR:CallRequest] AC (forwardToAnswerMachine( ) } CR [when 
(agent.state— busy) AND (agent.currentCallAmportance)] 

This rule stipulates that the call should be forwarded to the answer machine if the user 
is currently using the telephone (thus the device agent state is busy) and that the 
25 current call is important. Note that importance is a fuzzy variable. Thus, the rule 
strength of this rule will be equal to the value of the importance of the current call. 

The Call-Waiting agent contains the following rule. 

• PljcwJ 0+ [on CR; CallRequest] CW {signalCallWaiting( ) } agent [when 
30 (agentstate- busy) AND (CRAmportance)] 

This rule stipulates that the user should hear the call- waiting signal if he or she is 
currently on the telephone and the incoming call is important. Again, the rule strength 
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of this rule willbeequal to the value of the fuzzy variable Ctaporrrmce, which 
indicates the importance of the incoming call. 

Thus in the situation of a long-distance call request being sent to mis device 
, agent. Initially, the call is given an importance of 90% (using rule P L a 2) . Once the 
call has been esmblished, the importance of me call is se, to 0.9-0.9 - 81% (using rule 

Ma?). 

Now in the event mat another user tries to make a local call to mis user, the 
„ importance of the call requested will be 60% (using rule Pf_a/). A conflict occurs 
between the AC and CW modules. The rule PIjkI has the same strength as the 
importance of the current call, thus i, will be equal to 0.81. On the other hand, the rule 
Pl cwl tas the same strength as the incoming call, which is 0.6. In mis case. «_«7 
wi« take precedence over « _«l and the incoming call will be directly forwarded . 
15 the answer machine. 

If a request to establish another long-distance is sen. to the agen. while the 
user is still making me other long-dirtance, talk, incoming call importance wtl> be 
equal .o 0.9. The rule s«engm of is 0.9, while Mrrc/sUengm will reman," 

2o 0.81 Xar/ will uke precedence over PI. -J -* *• — **» b * "* ' 

call-waiting signal. '. 

The foregoing example demons.ra.es me use of fuzzy logic in the system of 
the present invention. More specifically, mis example illusu-a.es how fitzzy logte 
25 constraints can be used to allow the user to alter the reaction of the system dependmg 
on the user's own preferences, thereby giving real call control to the end user. 

In the example scenario depicted in Figure 5, me use of fuzzy logic is 
demonstrated in accordance with the invention to resolve a conflict between mulupl. 
30 agents. 
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In this example user A wants to establish a conference call with users B and C. 
User A does not want any of the telephone calls placed to B and C to be forwarded to 
an answer machine or a secretary/Both B and C are not available. B has forwarded all 
telephone calls to her answer machine, while C has forwarded all telephone calls to 
his secretary. User C has left a report with his secretary that she should read to the 
others in the conference call. 

Consider firstly the scenario of user A sending a Call-Request (CR) to user B. 
The device-agent of A posts the following Call-Request on the event-blackboard: 

• CR.caller=A, called=B, id = Xl t noForward=80% 

The id of the call request is set by the originating agent to identify this request if 
further processing is required. The no-Forward parameter is set by the caller to 80%, 
indicating that the originating agent prefers not to forward this call. For simplicity, 
assume also that the only entity that is interested in this call request is the called-agent 
B. 

The device agent of B (Agent B) contains two sub-agents: a Termination-agent 
(B.T) and an Answer-Call-agent (B.AC). 

Agent B also has an attribute, available, set to false. Agent B also contains the 
fuzzy variable forwardToVoiceMail parameter, which is set to 10%, indicating that 
persons who call her are permitted to be forwarded to her answer machine, but 
without forcing them to be so forwarded. 

B.T contains the following policies: 

• PIJST1 0+ [on CR:CallRequesL called^ B] B. T {acceptCall( ) } CR [when 
(B.available-trueJJ 

• Pl_BT2 0+ [on CR:CallRequesL called=B] B. T (noAction( ) } CR [when 
(B. available = false)] 

B.AC contains the following policies: 
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(B available = true)] 
. n BAC2 0* [on CR:Ca„Reaues,,a„ea--BJ B.AC tfin-«W» 

^.available - 'false) AND (B.forwardToVoicMail)] 

i 

The output of B.T is no-Action (nonaction is always given a truth value of 
0%), white B.AC chooses to forward the ca.1 u, the answer machine, with a uu* 
vaiue of 10%, which is the value of ^ fo^.To-Vo^Ma,, parameter. Agen, B 
aAta.es between the output of me rwo modules and in response chooses/omW- 
Call. Thus, the result of mis even, is a call forward on the call request. 

The system then asks for me permission from the originator of the even, (i.e. 
Agent A). 

Agent A contains the following rule: 
. PlA1A .ACror™^10)C*:Ca>l*^U<CX.noFor»aray 

This nde indicates ma, A refuses ,o forward mis cai. wim adegree of mt* of 80* 
which is the value of the fuzzy input variable no-Forward. ^^"^""j^*^ been 
Exeepnon even, is therefore generated. This even, indicates me ac„o 0 ma, h^ b=« 
Led, the even, ma, has generated mis actio, ft. agen,(s) ma, suggest ,he aeon 
as well as the agent(s) that refused the action. 

The arbirra.or agen, de,ects this exception opens a channel for me involved 
agents to start negotiating. All of me sub-agents thsrt have suggested ^acUonjpost 

refusing agen.(s) do me same, wirh , he following results: 

. B.T -> No-Action t 0% 

. B.AC-* forward-Call, 10% 

• A no-forward, 80% - 
. rnelggesi^-C^ action hasavalueof,^ 

gl. L. the arhi,ea,.r agen, deduces ma, mis action can no, be al.owed. T*e 
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only other action is No-Action. The arbitrator agent realizes that no other action is 
permitted and therefore refuses the call request. 

Turning now to the scenario of user A sending a Call-Request (CR) to user C. 
5 The clevice-agent of A (Agent A) posts the following Call-Request to the event- 
blackboard: 

• CR caller = A, called = C id = X2, noForward=80% 

The device agent of C (Agent C) contains two sub-agents, a Termination-agent 
10 (C.T) and a Call-Forward-agent (C.CF). Agent C has the attribute available set to 
false. Agent C also contains the fuzzy variable forward-Call 9 which is set to 10% in 
order to allow the calls to be forwarded to Cs secretary. Agent C also contains the 
following policy: 

• PljCJ 0+ [on CR:CallRequest.called=C, caller^A] C {set(0.95 ) } forward-Call 
15 This rule is set by Agent C to indicate that it is waiting for a call from A. When this 

call is received, the value of forward-Call is to 95% in order to express the preference 
of use C to forwarded this particular call to his secretary. 

C.T contains the following policies: 
20 • PljCTl 0+ [on CR:CallRequest.called=C] C. T {acceptCallf ) } CR [when 
(C.available— true)] 

• P1JCT2 0+ [on CR:CallRequest.called=C] C.T (noAction() } CR [when 
(C.available- false)] 

25 C.CF contains the following policies: 

• PIJCCF1 0+ [on CR:CallRequest.called=C] C.CF (noAction() } CR [when 
(C.available = true)] 

• P1_CCF2 0+ [on CR. CallRequest. called=C] C. CF {forwardCall( ) } CR [when 
(Cavailable = false) AND (C. Forward-Call)] 
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When the call request is received from Agent A, Agent C sets the value of 
forward-Call to 95%. The two sub-agents of C suggest no-Action and forward-Call 
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with a degree of truth of 95. Again, the system asks for the permission of the 
originator of this event, which is Agent A. 

Agent A activates the rule Pl_Al and refuses the call forward. A No- 
5 Permission-Exception event is generated again and the arbitrator agent opens a . 
channel for the involved agents to start negotiating. The following rules are posted in 
this special purpose channel. 

• C.T -> No-Action, 0% 

• C.CF-* forward-Call, 95% 
10 • A -> no-forward, 80% 

The suggested forward-Call action has a value of 95%, while no-forward^ a 
value of 80%. The arbitrator agent therefore overrides the objection of A and the 
call is forwarded to C's secretary. 

IS 

The arbitrator is responsible for handling conflict between multiple agents. 
The following portion of this disclosure describes in detail how the arbitrator decides 
what to do in the scenario of Figure 5. 

20 Initially, the arbitrator receives the following tuple: 

• Event-Name: Exception 

• Event-Identifier: X3 

• Cause: No-Permission 

• From: A 

25 • Originating-Event: 

• Event-Name: Call-Forward 

• Event-Identifier: X2 

• By: B 

• To: Answer-Machine agent 
30 • Originating-Event: 

• Event-Name: Call-Request 

• Event-Identifier: XI 
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• Parameters: {no-Forward: 80%) 

• Type: 1 

• From: A 

• To:B 

i 

5 

In the event of a passive arbitrator being used, which applies equal weights for 
every agent involved in the exception, the arbitrator opens a separate channel and 
posts the events on it, starting with the oldest event (the inner event). Only the 
involved agents, A and B in this case, are allowed to reply to this event. The result of 
10 event XI is that the termination agent of B suggests no-Action. The no-Action result 
is automatically assigned a degree of truth of 0%, to give it the lowest priority. The 
call forward agent of B suggests a forward-call with a degree of truth of 10%. The 
result of event X2 is that A refuses the forwarding of the call, with a degree of truth of 
80%. 
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This gives rise to the following results: 
B.T: no-Action 0% 
B.AC: forward 10% 
A: no-forward: 80% 



The truth- vsdue of the forward action is recalculated as equal to the original 
truth-value of the action, minus the truth- value of the permission refusal. Thus, 
forward = 1 0%-80% « -70%. No- Action still equals 0%. The arbitrator therefore 
chooses No-Action, and the call request does not generate any further events. The 
25 sender of the call request interprets this as a refusal to his call. 

If the same mechanism is applied for the second case, then: 

♦ B.T: no- Action 0% 

• B.AC: forward 95% 
30 • A: no-forward: 80% 
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The final truth-value of forward is = 95%-80% = 1 5%. No-Action still equals 
0%. The arbitrator therefore chooses the action with the highest degree of truth (i.e. it 
will choose to forward the call). 

- It should be noted that an equal weight arbitrator is utilized. If a weighted- 
arbitrator had been used, the final truth-value of the action that didn't receive the 
permission would be equal to the truth-value of the action, multiplied by its weight, 



minus 



the truth-value of the denial multiplied by its weight. 



Other embodiments and variations of the invention are possible. For instance, 
the examples and embodiments set forth herein relate to the field of 
telecommunications, and more particular to call processing within telephone systems. 
However, the principles of the invention may be applied to any multi-agent system 
which is susceptible to feature interaction conflicts (e.g. network resource 
management, costing systems, stock and bond trading systems, etc.). All such 
additional embodiments and applications are believed to be within the sphere and 
scope of the invention as defined by the claims appended hereto. 
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What is claimed is: 

1 . An event based model for detecting feature-interaction in a multiple-agent 
system comprising: 

5 an Event Agent for posting events from and for registering events of interest 

to respective agents in said multiple-agent system; and 

A Blackboard for receiving said events posted by said Event Agent and 
generating responses to said Event Agent for identifying said events of interest, 
whereupon said Event Agent informs each of said multiple agents which has 
10 registered for said events thereby detecting feature-interaction between said events. 

2. The event based model of claim 1, wherein said Event Agent includes means 
for registering said events of interest via one of either event notification by which one 
or more of said agents are notified of an occurrence of an event, or event handling by 

15 which one or more of said agents exerts control over said event. 

3. The event based model of claim 2, further comprising an Arbitrator for 
resolving conflicts between a plurality of said agents which have registered for 
handling of an event. 

20 

4 A method of resolving feature interaction conflicts within an agent, 
comprising the steps of: 

assigning fuzzy parameters of various degrees of truth to attributes of rules for 
defining user preferences associated with predetermined feature events affecting said 
25 agent; and 

comparing said fuzzy parameters and in response selecting one of said rules 
having the highest degree of truth of said fuzzy parameters for controlling said agent 

5. The method of claim 4 further comprising the step of modifying said fuzzy 
30 parameters in the event of intervening events affecting said agent. 
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6. In a multi-agent system using a tuple space for communicating between 
multiple agents, a method of resolving feature interaction conflicts between a plurality 

of agents, comprising the steps of: 

assigning fuzzy parameters of various degrees of truth to attributes of rules for 
defining user preferences associated with predetermined events affecting respective 

ones of said agents; 

posting a predetermined one of said events from a requesting one of said 

agents on said tuple space; 

comparing the fuzzy parameters assigned to the attributes of rules for defining 
user preferences associated with said predetermined one of said events affecting at 
least one recipient agent and in response selecting one of said rules having the highest 
degree of truth of said fuzzy parameters for initiating a predetermined one of said 
events on said requesting one of said agents; and 

in the event that said requesting one of said agents refuses said predetermined 
one of said events then opening a communication on said tuple space for arbitrating 
between said requesting one of said agents and said at least one recipient agent. 

7. The method of claim 6, wherein said step of opening a communication on said 
tuple space for arbitrating between said requesting one of said agents and said at least 
one recipient agent further comprises the steps of posting suggested events having 
respective degrees of truth from respective ones of said requesting agent and said at 
least one recipient agent to said tuple space and choosing from said suggested events 
the event having the highest degree of truth. 

8 The method of claim 7 further comprising the step of assigning multiplicative 
weight values to said respective degrees of truth for prioritizing influence of the rules 
affecting predetermined ones of said agents over other ones of said agents. 
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